The redundant union. Dispatcher.dispatch() (packages/core/src/shared/dispatcher.ts:159) declares its return type as Promise<JSONRPCResponse | JSONRPCErrorResponse>. But JSONRPCResponse is itself already a union: packages/core/src/types/schemas.ts:170 defines JSONRPCResponseSchema = z.union([JSONRPCResultResponseSchema, JSONRPCErrorResponseSchema]), and spec.types.ts:257 confirms type JSONRPCResponse = JSONRPCResultResponse | JSONRPCErrorResponse. TypeScript collapses A | B where B ⊆ A to just A, so the declared type is exactly equivalent to Promise<JSONRPCResponse> — the | JSONRPCErrorResponse adds nothing.

The over-wide okResponse() type. okResponse() (packages/core/src/shared/dispatcher.ts:195) unconditionally builds { jsonrpc, id, result } — always a success-shaped response. Yet it's typed as returning JSONRPCResponse (the success-or-error union) when the precise type is JSONRPCResultResponse. A caller that wanted to access .result directly would be forced to narrow with a type guard even though the function can never produce an error variant.

Why this isn't a behavior bug. Both signatures are correct in the sense that the actual return value is assignable to the declared type — they're just wider than necessary. Every current caller (Protocol._onrequest in protocol.ts) immediately passes the result to transport.send(), which accepts the full JSONRPCMessage union, so nothing observable changes. The pre-PR _onrequest code also typed its locally-built success object as const response: JSONRPCResponse, so this carries over a pre-existing widening — but since the PR is introducing these new exported helpers in a brand-new file, it's a good moment to get the types exactly right.

Why fix it. okResponse and errorResponse are now exported from packages/core (export * from './shared/dispatcher.js' in index.ts), so they become public-ish API for sibling packages and the upcoming _dispatchStateless path. Tighter return types give downstream callers better narrowing for free and document the contract ("this always succeeds") without needing a comment.

Concrete walk-through.

1. A future consumer calls const r = okResponse(1, { tools: [] }).
2. They want to read r.result. With the current signature r: JSONRPCResponse, TypeScript reports Property 'result' does not exist on type 'JSONRPCErrorResponse' and forces an if ('result' in r) guard.
3. With r: JSONRPCResultResponse, r.result type-checks directly — matching the function's actual guaranteed behavior.

Suggested fix.

async dispatch(request: JSONRPCRequest, ctx: ContextT): Promise<JSONRPCResponse> { … }

export function okResponse(id: JSONRPCRequest['id'], result: Result): JSONRPCResultResponse { … }

errorResponse is already correctly narrowed to JSONRPCErrorResponse, so only these two annotations need to change. Filed as a nit since there's zero runtime impact.

What the issue is. Four new comments added by this PR reference code that does not exist yet:

• packages/core/src/shared/protocol.ts:279 — /** The handler registry. Both \_onrequest` and `_dispatchStateless` route through it. */`
• packages/core/src/shared/dispatcher.ts (class JSDoc, ~line 55) — "Both the legacy connect/_onrequest path and the 2026-06 stateless dispatch path route through dispatch."
• packages/client/src/client/client.ts:288 — "…so it applies to both the legacy `_onrequest` path and the 2026-06 dispatch path."
• packages/server/src/server/server.ts:182 — "…so it applies to both the legacy `_onrequest` path and the 2026-06 dispatch path."

_dispatchStateless appears nowhere in the codebase except inside the comment at protocol.ts:279, and there is no "2026-06 dispatch path" implemented anywhere. These are forward references to PR #2131.

Why it matters. The repo's own review guidance flags "prose that promises behavior the code no longer ships" and "any claim the diff doesn't back." Once this PR merges, a contributor reading Protocol who sees "Both `_onrequest` and `_dispatchStateless` route through it" and greps for _dispatchStateless will find zero hits. They have no way to know whether the symbol was renamed, removed, or never landed. _onrequest already calls _onrequest legacy — there is no "legacy" vs. "new" distinction observable in the merged code, so the dichotomy the comments draw doesn't exist for a reader of the codebase at this commit.

Step-by-step proof.

1. Merge refactor(core): extract Dispatcher; Protocol composes it #2130 in isolation.
2. Open packages/core/src/shared/protocol.ts at line 279: /** The handler registry. Both \_onrequest` and `_dispatchStateless` route through it. */`
3. Run grep -rn _dispatchStateless packages/ → only the comment itself matches. There is no method, no export, no test.
4. Open packages/server/src/server/server.ts:182: "…applies to both the legacy `_onrequest` path and the 2026-06 dispatch path." → there is exactly one path, _onrequest. Nothing distinguishes it as "legacy".

Why this is a nit and not a blocker. The PR description openly states this is PR 3 of a 7-PR v2-stateless stack, and that #2131 ("HTTP-stateless") introduces _dispatchStateless. The author and reviewers have full stack context, the comments are accurate as a description of intent, and they will become literally true once #2131 merges. There is zero runtime impact. But comments live in the merged tree, not in the PR description — and PRs in a stack don't always all land, or land in order.

How to fix. Either qualify the references so they are true at merge time, e.g.:

/** The handler registry. \`_onrequest\` routes through it (and the forthcoming \`_dispatchStateless\` path, #2131). */

or describe only what exists today and let #2131 update the comments when it adds the second path:

/** The handler registry. \`_onrequest\` routes through it. */

The first option preserves the useful forward signal for reviewers of this stack; the second is the most conservative.